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(54)T1tle: METHOD AND SYSTEM FOR PLANNINa SCHEDUUNG AND MANAGING PERSONNEL 



C57)AbilnGt 

A method for planning, scheduling and managing personnel 
in an environment in wfaidi there is a varying workload by time of 
day and by day of week to be staffed with a team having a variable 
number of setvers (25). The method organizes the team of servers in- 
to a phualxty of management units, each mana gft meat u ni t having 
one or more groups of individual seivers. Tour templates (27), each 
descrfting a bounded work shift having work rules and operating 
(xmstraiiits. are then d ef i n ed. A forecast u then genetated (29) of an 
event load expected to occur during a forecast time period pi) and 
a number of servers required to service the expected event load dur- 
ing the forecast time period (33-39). A force management system ac- 
cording to the iovcotion includes a unique management display sys- 
tem for managing server schedules during a forecast time period. 
The invention also describes a forecasting method for the force ma- 
nagement system, and a method for predicting a number of agents 
required to provide a given service level in fbe management system. 
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METHOD AND SXSTEM FOS FIAHHIHGr 
SGHEDULIBG ARD HASAGIHG PESSOHHEL 

The present invention relates generally to 
computerized systems and methods £or planning, 
scheduling and managing personnel in an environment 
in which there is a varying workload by time of day 
and by day o£ week to be staffed with a variable 
number of servers. 

Force management systems for use in planning # 
scheduling and managing personnel in a telephone 
call center are known in the prior art. Such 
systems typically include a basic planning 
capability to enable a call center supervisor to 
forecast future call loads and the number of servers 
or "agents" necessary to service that load. Most 
prior art systems also include a simple scheduling 
capability which then functions to allocate agent 
work hours according to the staffing requirements 
that have been forecast. Agents are then manually 
or automatically assigned to fill the schedules. 
These systems usually also include other 
administrative and reporting capabilities. 

Prior art force management systems suffer from 
many disadvantages. Such systems rely on 
conventional time-series forecasting techniques to 
generate forecasts for a large block or unit of 
time, e.g., a month. These techniques then use 
fixed factors to decompose the monthly forecast into 
weekly, daily, and then hourly or smaller 
increments. This approach Is computationally- 
efficient but lends itself to accuracy only on a 
macro scale, e.g. month-to-month, as opposed to 
reflecting real changes in call volumes as they 
actually occur in the historical data for the call 
center. Prior art systems thus do not have the 
flexibility to be responsive to changing conditions 
so as to forecast future call loads and provide 
realistic scheduling of personnel to meet the 
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dTiiamic load requirements of a typical telephone 
call center. 

Moreover, the prior art systems are typically 
structured around a single call center location. 
5 Therefore, while telecommunications switching 
advances can effectively connect numerous locations 
together, there is no prior art management system 
that can provide efficient forecasting and 
requirements generation at a central location with 

10 schedule generation and schedule management at 
individual dispersed locations. Yet another 
disadvantage associated with prior art approaches is 
the inability of such systems to efficiently 
generate optimal workshifts ("tours*") for agents 

15 once forecasting is complete. Further, these 
systems do not have the capability to efficiently 
generate schedules to satisfy agent preferences, 
availability and seniority. 

The deficiencies of prior art force management 

20 systems have given rise to a curious result. In a 
call center environment, telephone call center 
supervisors are forced to manage their personnel 
based on the capabilities of their force management 
system, as opposed to the capabilities of their 

25 switching system and their staffing resources. 

It would therefore be desirable to overcome the 
problems associated with such prior art force 
management systems. 

It is an object of the present invention to 

30 provide a force management system and method for 
planning, scheduling and managing personnel in an 
environment in which there is a varying workload by 
time of day and day of week to be staffed with a 
variable number of servers. One such environment is 

35 a telephone call center in which incoming calls are 
delivered among a plurality of agents for response. 
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Nhile the following description uses a telephone 
call center as a representative example of one 
environment for implementing the teachings of the 
present invention, the invention is not to be 
5 construed as limited to the call center 
application. Indeed, the principles of the 
invention are applicable to any work environment in 
which there are required to be varying worKloadS/ by 
time of day and day of week, to be staffed with a 

10 variable number of servers. 

It is another object of the invention to 
describe a personnel resource management system and 
method for managing large numbers of agents with a 
single system wherein groups of operators can be 

15 geographically-dispersed but still handle the same 
call type. The invention thus provides the 
flexibility and control to properly take advantage 
of the capacities of modern digital switches. 

More specifically, the present invention 

20 advantageously provides a division of functionality 
and control between a force management central 
center, which is responsible for longer term 
planning and administration, and a plurality of 
local management units responsible for scheduling 

25 and daily management. Preferably, at least one 
management unit or "MU* is located at a geographical 
location distinct from other management units of the 
system. This architecture provides the flexibility 
to accomodate significant changes in the 

30 organization and configuration of call handling 
units and the relationship between them. 

It is another object of the invention to 
provide a management system for personnel of a call 
center which includes tools to develop and adjust 

35 short term forecasts to quickly reflect special 
call-handling events and to develop forecasts that 
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capture long-term variations in call activity. In 
particular, the invention generates a forecast of a 
call load expected to occur during relatively small 
individual future time periods, e.g., half hour 
5 increments of a work day, as well as the number of 
agents required to service the expected call load 
during each individual period. This technique is 
the opposite from prior art time-series forecasting 
wherein forecasts are generated in a "top* down 

10 approach starting with a large forecasting period, 
e.g., a month or a week, and using fixed factors to 
decompose the forecast into smaller units, e.g., a 
day or a half -hour. The forecasting technique of 
tike present invention also advantageously reflects 

15 changes in call activity which occur as a result of 
the fact that the relative position of a period in a 
month affects call volumes. The invention therefore 
provides much more accurate forecasts over prior art 
techniques • 

2® It is still another object to provide an 

efficient method of generating workshifts or "tours* 
for agents of a workplace that optimises the 
utilization of operator staff. Another object is to 
provide automatic scheduling of the agents to these 

25 tours taking full account of agent availability, 
preferences, sonority and fairness. 

It is a further object of the invention to 
provide a computer-based force management system and 
method for a telephone call center that plans 

30 personnel requirements in line with changing call 
volumes in a manner that service level requirements 
are met at the lowest possible cost. 

It is still another object to provide a force 
management system which provides an easy-to-use 

35 interface to enable supervisors to view call 
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forecasts and schedules £roin multiple sites in the 
call center. 

It is a further object to provide a force 
management system having a unique schedule 
5 management visual display to enable supervisors to 
adequately monitor and revise schedules of agents to 
insure that call handling responsibilities are met. 

Yet another object is to provide a force 
management system that includes a unique performance 
10 analysis visual display which enables supervisors to 
review detailed real-time data and make quick, 
informed staffing decisions in response thereto. 

In one basic embodiment of the invention, these 
and other objects of the invention are provided in a 
15 method for managing a team of agents at a telephone 
call center, comprising the steps of: 

(a) organizing the team of agents into a 
plurality of management units « each management unit 
having one or more groups of individual agents; 
20 (b) defining one or more tour templates each 

describing a bounded work shift having work rules 
and operating constraints; 

(c) generating a forecast of a call load 
expected to occur during individual future time 

25 periods and a number of agents required to service 
the expected call load during each individual period; 

(d) allocating the expected call load among 
the plurality of management units; 

(e) correlating the tour templates with the 
30 forecast to generate a set of tours for each 

management unit, each tour defining a predetermined 
daily work schedule for a theoretical agent of the 
management unit; 

(f) assigning the individual agents of each 
35 management unit to the generated tours for the 

management unit; and 
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(O) generating a schedule for each individual 
agent of the management unit. 

Alternativel7# steps (e), (£) and (g) are 
iiiiplemented together to automatically assign the 

' 5 individual agents of each management unit to the 
generated tours for the management unit according to 
agent preferences, availability, senority and 
fairness f and then producing schedules for each 
individual agent. 

10 The organization of the team of agents into 

management units provides significant advantages 
over the prior art in that it enables scheduling and 
management of large, distributed teams of call 
center agents. Management units are generally 

15 . located at different physical locations. Therefore, 
a number of small call center offices can be 
interconnected and function as one large, efficient 
call-handling team. Bach management unit, however, 
is managed locally and thus can have its individual 

20 work rules and hours of operation. Such individual 
management of the units facilitates local control of 
staffing and the ability to handle work rules that 
may vary from office to office. 

The invention also facilitates the efficient 

25 management of the individual agents of the 
management unit based on real-time performance 
statistics and meaningful display of the generated 
agent schedules. In particular, unique visual 
displays of agent schedules and management unit 

30 performance are provided to enable local supervisors 
to make fast, informed staffing decisions for their 
management unit. The schedule management display is 
advantageously built around the display of a "time 
line" for each agent of the management unit, with 

35 each unit in the time line preferably corresponding 
to a predetermined period of time, e.g., a fifteen 
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minute interval. The time line for each agent 
further includes one or more user-defined schedule 
activity codes therein, e.g., 'B** for break, *L" for 
lunch, "m" for meeting, etc., £or representing the 
5 agent's planned status for the day and the nature of 
any activities that might prevent the agent from 
attending to incoming calls. Preferably, different 
activities are displayed in contrasting colors 
according to activity class denoting potential 

10 availability. The system further enables the 
supervisor to dynamically edit the agent schedules 
and display lists of agents and their schedules 
sorted by predetermined criteria such as agent 
names, members of a carpool, schedule start times, 

15 schedule end times, agents having lunch breaks at 
lis 30, etc. 

The schedule management display thus provides a 
unique time line (as opposed to a textual) 
representation of agents within a management unit to 

20 enable the supervisor to visualize occupancy and 
potential staffing problems. The schedule 
management display cooperates with the related 
performance analysis screen which enables the 
in-charge supervisor to obtain a meaningful view of 

25 what call activity has actually occurred, a best 
guess estimate of what call activity will occur, and 
a means of making staffing decisions based on such 
information. By switching back and forth between 
the schedule management and performance analysis 

30 screens, the in-charge supervisor can make informed 
staffing decisions. 

Staffing changes at the management unit are 
transmitted back to the centralized computer of the 
force management system and then regularly broadcast 

35 back to the other management units of the system. 
The performance analysis screen at the management 
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unit is thus continuously updated (in real-time as 
data is received) with modified team call handling 
performance data. 

The present invention also includes an 
5 intra-day reforecasting capability which operates 
automatically as new data is received (data is 
usually received every fifteen minutes and posted 
every half-hour). Intra-day forecasting continually 
looks at the performance of the system and the 

10 original forecast data up to the time of the day for 
which data has been received. The systra 
reforecasts the conditions expected for the rest of 
the day using a reality weighting factor, which 
takes into consideration the amount of data received 

15 (i.e., how early in the day the intra-day reforecast 
is being computed) . 

The system also includes a "what-if" 
reforecasting capability to permit the call center 
supervisor (in the case of the overall team) or the 

20 local in-charge supervisor (in the case of the 
management unit) to determine the effects on team 
service level if the number of available agents is 
altered in a particular management unit. 

The foregoing has outlined some of the more 

25 pertinent objects of the present invention. These 
objects should be construed to be merely 
illustrative of some of the more prominent features 
and applications of the invention. Many other 
beneficial results can be attained by applying the 

30 disclosed invention in a different manner of 
modifying the invention as will be described. 
Accordingly, other objects and a fuller 
understanding of the invention may be had by 
referring to the following Detailed Description of 

35 the preferred embodiment. 
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For a more con^lete understanding of the 
present invention and the advantages thereof, 
reference should be made to the following Detailed 
Description taken in connection with the 
' 5 accompanying drawings in which: 

FIGURE 1 is a block diagram of the basic 
architecture of the force management system of the 
present invention; 

FIGURE 2 is a schematic representation of how a 
10 team of agents is organized into groups of 
management units according to the invention; 

FIGURE 3 is a flowchart showing the basic 
functional steps involved in force management 
according to the invention; 
15 FIGURE 4 is a schematic data flow diagram of 

the functional architecture of the central computer 
of the force management system of the present 
invention; 

FIGURE 5 is a representative tour teniplate 
20 according to the invention; 

FIGURE 6 is a flowchart describing the portion 
of the genrate forecast routine of FIGURE 4 used to 
generete a Call Volume forecast; 

FIGURE 7 is a flowchart describing the inverse 
25 Brlang C calculation portion of the generate 
forecast routine of FIGURE 4; 

FIGURE 8 is a representation of the Schedule 
Management screen of the present invention; and 

FIGURE 9 is a representation of the Performance 
30 Analysis screen in a forecast mode of operation; and 

FIGURE 10 is a data flow and functional 
architecture of one of the KU workstations showing 
the details of how the Schedule Management and 
Performance iuialysis screens are built; and 

35 
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FIGURE 11 is a detailed flowchart describing 
the tour/schedule generation algorithm of the 
present invention. 

Similar reference characters refer to similar 
5 parts or steps throughout the several views of the 
drawings . 

As described above, the force management system 
of the present invention is adapted for planning # 
scheduling and managing personnel in an environment 

10 in which there is a varying workload by time of day 
and by day of week to be staffed with a variable 
number of servers. In general, the servers will be 
required to respond to an event load which has been 
forecast to occur in the future. One such 

15 environment is a telephone call center in which, for 
example, an * event' is an incoming call to the 
center. For the remainder of the description, the 
telephone call center environment is described only 
for exemplary purposes and not by way of 

20 limitation. As seen in FIGURE 1, the force 
management system includes a personnel resource 
management central computer 12. This computer is 
connected to a management information system ("MIS") 
14, which forms part of a telephone switch and 

25 automatic call distributor ("ACD") system known in 
the prior art, namely, the AT&T 5BSS0 Switch 
ACD/NIS. It is known in the art that an ACD serves 
to automatically make telephone connections between 
agent workstations (not shown) and input telephone 

30 lines. As shown in FIGURE 1, the HIS 14 receives 
real-time data from the ACD and stores this data in 
the HIS database 16. Data is delivered to the force 
management system database IB of the central 
computer 12, preferably at fifteen (15) minute 

35 intervals. As will be described, agent schedules 
are delivered from the central computer 12 back to 
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the MIS 14 to enable the HIS 14 to determine 
adherence to the schedules. 

The centralized computer 12 is linked to a 
plurality o£ workstations 24 organised into a 
5 plurality of distinct groups or so-called management 
units 22e, 22b, ... 22n. With reference 
simultaneously to FIGURES 1-2, a "team" of call 
center agents is organised according to the 
invention into the plurality of "management units,* 

10 each management unit CMU") having a predetermined 
number of agent groups. An MU is thus a set of 
agent groups that is managed locally as a single 
unit. In this manner, each management unit can have 
its individual work rules and hours of operation. A 

15 management unit can be and is often 
geographically-separate from other management 
units. Although not shown in detail, a single 
telephone switch may likewise be associated with 
more than one team, and more than one NU can be 

20 associated with more than one team. One team can 
therefore handle one call type while another team 
handles a second call type. Thus the system is 
designed to accomodate not only geographical 
dispersal of management units, but also multiple 

25 call types dispersed among multiple management units 
and multiple geographical locations. 

Referring now back to figure 1, each management 
unit has one or more supervisor workstations 24 
associated with each group of agents therein. Each 

30 of the workstations 24 includes a video display 
terminal, a keyboard for enabling entry of 
appropriate administrative commands to manage 
personnel resources, and a suitable control circuit 
for controlling communications between the terminal 

35 and the central computer via one of the lines 
26a-26n. As will be described, the supervisory 
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workstation 24 provides displays o£ status. The 
central computer is preferably an AT&T 3B2/1000 
Model 80. Bach supervisor workstation can be 
isipleioented using a personal computer system having 
5 a suitable 80286 or 80386 processor, memory storage 
disks, input/output devices and connnmications 
interface equipment. 

Referring now to FIGURE 3, one method for 
planning, scheduling and managing a team of agents 

10 at a telephone call center according to the 
invention is described. The method begins at step 
25 by organising the team of agents into a plurality 
of management units, each management unit having one 
or more groups of individual agents. As noted 

15 above, the organization of the team of agents into 
management units provides significant advantages in 
that it enables scheduling and management of large, 
distributed teams of call center agents. Management 
units are generally located at different physical 

20 locations. Therefore, a number of small call center 
offices can be interconnected and function as one 
large, efficient call-handling team. Each 
management unit, however, is managed locally and 
thus can have its individual work rules and hours of 

25 operation. At step 27, one or more tour templates 
are defined, each template describing a bounded work 
shift having work rules and operating constraints. 
At step 29, a forecast is generated of a call load 
expected to occur during individual future time 

30 periods, e.g., half hour increments, and a number of 
agents required to service the expected call load 
during each such individual period. As will be 
described, forecasting according to the invention 
takes advantage of the statistical observation that 

35 the best single predictor of call volumes in any 
given period is the corresponding period, by time of 
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day and day o£ week, of previous weeks. Forecasting 
of call volumes also relies on other factors such as 
the relative position of various days with a given 
oonth. According to the inventionr short-term agent 
5 requirements are based on factors such as call load 
forecast, service level objective, expected agent 
occupancy and budgeting considerations. 

Following the generation of a forecast, the 
method continues at step 31 to allocate the expected 

10 call load among the plurality of management units. 
This function enables the centralized computer 12 of 
the overall team to distribute the responsibility 
for answering calls according to expected available 
staffing as administratively determined. Moreover, 

15 the allocation is variable by each half-hour of each 
day of the week. This operation enables the call 
center to realize significant facilities and 
management cost savings. For example « if there are 
four ISU*s expected to have equivalent amounts of 

20 staffing but one MU, e.g., MUl, closes one hour 
before the other MU's, the call center supervisor 
can setup the allocations for each HU at 25% until 
the end of the day, when the other three Mil's are 
then each allocated 33.3% of the calls. When MUl 

25 closes, no falloff in service level then occurs. Of 
course, in operation, incoming calls always go to 
the first available agent, regardless of the 
location of that agent. 

At step 33, tour templates are correlated with 

30 the forecast to generate a set of "tours" for each 
management unit, each tour defining a predetermined 
daily work schedule for a theoretical agent of the 
management unit. The method continues at step 35 by 
assigning the individual agents of each management 

35 unit to the generated tours for the management 
unit. At step 37, a schedule is generated for each 
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individual agent o£ the management unit. 
Thereafter « once a work shift begins at step 39, the 
shift supervisor for the management unit manages the 
agents through the use of a novel user interface as 
5 will be described in more detail below. 

Referring now to FIGURE 4, a schematic data 
flow diagram is shown of the functional architecture 
of the central computer 12 of the force management 
system. As seen in FIGURE <, the HIS 12 provides 

10 the force management system with statistics 
concerning incoming calls and the activities of the 
agents in responding to those calls. The force 
management system preferably processes data based in 
thirty (30) minute intervals. Raw statistical data 

15 is available from the HIS every 15 minutes « 
therefore, the system includes a Results database 44 
for storing the raw data from the HIS 12. Commands 
entered via a management workstation 24 are used to 
revise the data where appropriate. The revised data 

20 is then used by a generate forecast routine 46 which 
generates forecasts that are then stored in a 
Forecasts database 46. Initially, two basic 
elements are forecast: Call Volume and Average 
Handling Time ("AHT"). Call Volumes and AHT are 

25 forecast in preferably half-hour increments. In the 
call center application, AHT represents the average 
time an agent takes to handle a call. 

In order to generate the staffing requirements, 
the generate forecast routine 46 uses three (3) 

30 other parameters, Service Objective, Occupancy and a 
Budget factor, provided from an administrative 
database 50. The Service Objective is the level of 
service which is desired to be provided to 
customers. Service Objective is selected by the 

35 system operator and is expressed as a percentage of 
calls answered within a set time. Occupancy is the 
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measure of the percentage of time in which agents 
are handling calls. The Budget factor represents an 
allowance for unscheduled unavailability such as 
absences or vacations* The forecast data and 
5 administrative parameters are used by the generate 
forecast routine 46 to calculate a number of 
so-called Full Time Equivalent ("FTE") agents for 
various periods. An FTE is a scaleless number which 
depends on the time scale being examined. Thus, for 

10 a half -hour period, an FTE of fifty (50) means that 
fifty (50) agents are available for thirty (30) 
minutes each or that one hundred (100) agents are 
available for fifteen (15) minutes each, etc. 

After generating the staffing requirements for 

15 each interval, the force management system enters a 
scheduling function. The purpose of the scheduling 
function is to allocate work hours according to the 
staffing requirements that have been forecast. 
Scheduling has three basic components: tour 

20 generation, agent assignment and schedule 
generation. A tour is a given work schedule for a 
set number of working days and includes a start 
time, an end time, break time(s), meal time, 
workdays and tour length. Tour generation is the 

25 process of matching the staffing requirements with 
the staffing possibilities, as defined by staffing 
restrictions such as hours of operation, permissible 
tour templates and maximum and minimum number or 
particular tour templates. A tour template defines 

30 the boundaries of permissible tours, e.g., the 
earliest and latest agent start times, maximum hours 
per week, number of breaks, etc. FIGURE 5 shows a 
representative tour template. According to the 
invention, tours are generated so that staffing 

35 requirements and staffing restrictions are optimized 
for a low level of over- or under-staffing. 
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Referring now back to FIGURE 4, in one 
embodiment of the invention a generate tours routine 
52 is used to create tours for "theoretical" agents 
of each management unit based on the tour templates 

' 5 and the forecast FTB requirements for a particular 
period. Tours, which are stored in Tours database 
53, at this point do not have particular agents 
associated with them. Thereafter, the 8upervisor(s) 
assign agents to generated tours using a list of 

10 named agents. Alternatively, agents can be assigned 
using an automatic process instead of manually as 
will be described below. The daily schedules for 
every agent are then prepared by a generate 
schedules routine 54 and stored in Schedules 

15 database 56. Time utilization reports 57 can be 
generated from the Schedules database 56 if desired. 

Referring now to FIGURE 6, the portion of the 
generate forecast routine 46 of FIGURE 4 used to 
forecast Call Volume is shown in detail. AHT is 

20 forecast in a similar manner. As described 
generally above, forecasting according to the 
present invention focuses initially on individual 
small periods of time, e.g., half-hour increments, 
as opposed ^to macro or lengthy forecasting periods 

25 such as months or weeks. This approach provides 
significant improvements over the prior art, 
especially where comprehensive and consistent 
historical data exists for use in generating the 
forecast. 

30 Forecasting is based on the statistical 

observation that the best single predictor of future 
call volumes in any given period is the 
corresponding period, by time of day and day of 
week, of previous weeks. The best predictor of next 

35 Monday at 10:30 a.m. is last Monday at 10:30 or 
rather the series of such recent time periods; i.e.. 
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the most current data available from the MIS. 
Indeed, if the forecast is being performed for 
example on January 15, 1991, then the very best data 
for use in generating the forecast according to the 
5 invention is some period of time (e.g., 13 weeks) 
leading up to and ending January 14, 1991. As will 
be seen, this is the technique implemented by the 
present invention. Moreover, the technique also 
recognises and uses calendar variability factors, 

10 i.e., the fact that the relative position of a 
period in a month affects call volumes, to further 
weight the forecast. For example, often the first 
Monday in a month has a characteristically different 
volume from the third Monday. According to the 

15 invention, forecasting is carried but by determining 
the relative weight of these factors in the roost 
current historical data, as determined by a 
statistical analysis. 

More specifically, and with reference to FIGURE 

20 6, there is shown a flowchart of a novel method for 
generating a forecast of Call Volumes expected to 
occur in a telephone call center during a future 
time span. The method uses force management system 
historical database which is derived from results 

25 received from the HIS. THE FMS database includes 
historical call volume data preferably up to the 
very last day (i.e., the "previous day") before the 
day in which the forecast is being generated. The 
method begins at step 31 by scanning the historical 

30 data over a predetermined time period (e.g., two 
years) to produce a historically-observed "growth 
rate,* i.e., a long-term increase or decrease in 
call volumes. The method then continues at step 33 
by defining a "forecast base period* corresponding 

35 to a predetermined time period (e.g., 13 weeks) 
ending with the previous day. 
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Thereafter, a first processing loop begins at 
step 35 for each individual time increment of a 
given day of the week, beginning with a first 
individual time increment of a week, continuing 
5 increment-by-increment and ending with a last 
individual time increment of the week. Each 
increment is a half -hour period and thus the loop^ 
for example # begins with the 12:00-12:30 a.m. 
increment on Sunday morning and continues with each 

10 individual increment (12:30-1:00 a.m., 1:00-1:30 
a.m. ...) throughout Sunday* Once Sunday is 
complete, the loop continues with Monday, and 
likewise to the end of the week. The loop is 
complete upon processing of the 11:30-12:00 midnight 

15 increment on Saturday night. Of course, depending 
on the hours of operation of the team during the 
future span, it should be appreciated that parts of 
the looping can be skipped. 

The following steps are then performed within 

20 the first processing loop for each individual time 
increment. At step 37, the call volume data in the 
forecast base period is averaged. Using the first 
increment described above, this step would average 
the Sunday 12:00 call volume data for each of the 13 

25 weeks in the forecast base period. At step 39, the 
standard deviation of the averaged call volume data 
is calculated. Any call volume data that deviates 
two standard deviations from the mean is then 
discarded at step 41 to prevent biasing of the 

30 forecast. At step 43, the call volume data 
remaining in the forecast base period is weighted. 
Weights are assigned to the data under one or more 
predetermined criteria such as the age of the data, 
whether the data is true data (received from the 

35 HIS) for the system or system initialisation data, 
etc. At step 45, this weighted data is then 
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averaged to generate a weighted average call 
volume. At step 47, the method continues by 
projecting the weighted average call volume into 
corresponding increments throughout the future time 
' 5 span. In other words, if the previous steps have 
calculated the weighted average call volume for 
Tuesdays at 9:00 a.m. to be 362, this figure is 
projected into each Tuesday/SrOO slot of the future 
time span. 

10 The last step in the loop in the generation at 

step 49 of a calendar factor (for the increment) 
from the forecast base period historical data. The 
calendar factor represents a relative weighting of 
call volumes by week of month. Each month is by 

15 convention separated into first « second, next to 
last and last weeks. By way of a simple example, 
assume the historical data shows that 110 calls were 
received during the particular half-hour on Monday 
of week 1 of the month in question, that. 100 calls 

20 were received during the corresponding half-hour on 
Monday of week 2, that 90 calls were received during 
the ha If -hour on Monday of the next to last week, 
and that 100 calls were received during the 
half-hour on Monday of the last week. Given 400 

25 total calls or an average of 100 for the particular 
ha If -hour /Monday, a calendar factor for the 
particular half-hour for Monday of week 1 would then 
be calculated as 110 (the actual number of calls) 
divided by 100 (the average number of calls) or 1.1; 

30 the calendar factor for the particular ha If -hour for 
Monday of week 2 would be 100/100 or 1.0, and so 
forth. If a month has a weekday occurring five 
times, the calendar factor uses these four variables 
and calculates the average of the second and next to 

35 last weeks as the intermediate week. The calculated 
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calendar factors are stored for the purposes to be 
described below. 

At step 51, a test is made to determine if the 
first day of the future time span is the next day 
5 (i.e./ the day after the forecast is being done). 
If not, then the future time span is son^time in the 
future and thus the growth rate must be extrapolated 
to compensate for unforecasted days between the 
previous day and the actual first day of the future 
10 time span. At step 53, the growth rate is therefore 
adjusted to reflect changes therein which would have 
occurred between the previous day and the first 
day. At step 55, the method continues by applying 
the gro%ffth rate, as a daily exponential rate of 
15 change, to the weighted average call volumes 
previously projected for the future time apan. The 
growth rate is applied (as a multiplier) on a 
day-to-day basis from the first day of the future 
time span to a last day of the future time span. 
20 Thereafter, the routine enters a second processing 
loop at step 57. 

The second loop is then performed for each 
individual time increment, from the first day of the 
future time span, continuing increment -by- increment, 
25 and ending with a last individual time increment of 
the last day of the future time period. The loop 
begins at step 58. As each new month is entered 
during looping, the method continues by generating a 
seasonality factor for each such new month. This 
30 factor is generated from the two (2) year historical 
data for each new month of the future time span, and 
it represents month-to-month percentage increases or 
decreases in call volumes. At step 59, the method 
continues by calculating a "net" seasonality effect, 
35 the net seasonality effect being based on the 
relative position in the month of a current time 
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incremeBt. In particular, the seasonality factor is 
calculated £rom month-to-month variations and then 
applied in a forward and backward manner from a 
month midpoint. For example, assume the historical 
5 data evidences that April call volumes ace 10% 
higher than March call volumes and that May volumes 
are 12% higher than April volumes. Using the 10% 
and 12% growth rates# step 57 applies implies a 10% 
growth rate (as a daily exponential rate) for each 

10 day between March 15 and April 15, and a 12% growth 
rate (as a daily exponential rate) for each day 
between April 15 and May 15. If the relevant time 
increment is in, for example, April 10th (which is 5 
days to April 15th and 21 days from March 15th), 

15 then the net forward seasonality factor for the 
increment on that day will be the forward rate of 
change raised to the 5th power. The net backward 
seasonality factor will be the backward rate of 
change raised to the 2l6t power. This approach 

20 eliminates sharp discontinuities in prior art 
forecasts which occur across monthly boundaries as 
growth rates change. 

At step 61, the calendar factor for the 
increment is retrieved. Finally, at step 71, the 

25 net seasonality factor and the retrieved calendar 
factor are applied (as multipliers) to the weighted 
average call volume as previously adjusted by the 
growth rate to complete the forecast for that 
increment. Once the second loop terminates, the 

30 method terminates. 

Although not described in detail above, data 
from so-called "special days** (e.g., Christmas, New 
Year's Day, etc.) occurring during the forecast base 
period is discarded before processing so that call 

35 volume deviations from the special days do not 
otherwise bias the forecast. Periods for which 
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there is no data £or the applicable hal£-hour period 
also do not affect the average because these periods 
are ignored in the averaging calculations. 

The method of FIGURE 6 advantageously 
5 eliminates the need for fixed factor distributions 
to distribute call volumes from months to weeks, 
from weeks to days, and from days to half -hour 
periods* The determination is built into the 
forecast method itself. This is a powerful, unique 

10 approach that overcomes the deficiencies of prior 
art time series forecasting. 

Although not discussed in detail, it should be 
appreciated that variations in the order of or 
aspects of the various steps shown in FIGURE 6 is 

15 within the scope of the inventive technique. For 
example, to the extent the future time span includes 
any special day, the forecast thereof is adjusted by 
the stored distribution and certain call volume 
adjustment factors for that special day. Moreover, 

20 for purposes of computation, the growth rate factor 
can be applied early on the process by setting up an 
array corresponding to each half -hour period of each 
day in the future time span. The average call 
volume for each half-hour (which will be calculated) 

25 is then set equal to an initial value (i.e., 1), and 
then the growth rate is applied as a daily 
exponential rate forward through the forecast as 
discussed above. 

The generate forecast routine 46 includes other 

30 novel features. In particular, it is known in the 
prior art to perform so-called "Erlang C" 
calculations to estimate a specific service level 
from call rates, average call handling time and the 
number of agents. According to the present 

35 invention, a method is described for using Erlang C 
in a unique manner in that it takes the call rate. 
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handling time and the desired service level to 
determine the necessary number of agents (i.e.,. the 
PTE). This is "backwards* £ron the way the Erlang C 
calculations are normally used. The service level 
5 is the percentage of calls answered within the 
service objective. For example* a service level 
goal might be that 80% of the calls are answered 
within 20 seconds. The forecasting method of the 
invention determines the number of agents necessary 

10 to provide a given service level specified rather 
than the service level provided by a given number of 
agents. The method also directly calculates for all 
possible combinations of service level time and 
service level percentage whereas the prior art 

15 either forces a set number of fixed numbers (e.g., 
70%# B0\ or 90% service levels) or extrapolates from 
such numbers. 

With reference now to FIGURE 7, a simplified 
flowchart diagram is shown describing a method for 

20 predicting a number of agents required to provide a 
given service level in a force management system. 
The service level is defined by a percentage of 
calls answered within a predetermined time. By way 
of brief background, the basic Erlang C formula set 

25 is shown below: 

P(W>t) m C(n,a) - k/k^B, where: 

A - a'*/(n-l)!(n-a) 

B • Summation (j«0 to n-1) a^/j! 

for Oc-acn. 

30 

P(w>0} • probability of a delay in agent service 

P(W>t} • probability of a delay > t seconds 

E(w} m expected delay of service 

N m waiting time 

C(n,a) -Erlang C formula 

t ■ service objective in seconds 

tau • average holding time 

mu - 1/tau 

lambda « average arrival rate (calls per second) 
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a m offered load in Brlangs (lambda times tau) 
n • number of agents 

Rote that lambda is the arrival rate in calls per 
second. Therefore, since tau is the time per call, 
5 the offered load or "Erlang* number *'b* has no 
units. If the number of available agents is less 
than or equal to the Erlang number, the number of 
calls waiting and the average delay will grow 
without bound. 

10 As described above, the Erlang C formula is 

used to calculate the probability of delay (and then 
the percentage of calls handled within some specific 
number of seconds of delay) given the arrival rate, 
average call handling time, and the number of 

15 agents. In the present invention, the disclosed 
method is used to predict the number o£ agents 
required to provide a given service level 
(percentage of calls answered within some number of 
seconds) . 

20 The method begins at step 73 by calculating the 

offered load "a.* At step 75, the Erlang C 
calculation C(n,a) is run for n-a*i-l, which is the 
minimum of agents for which a meaningful Erlang C 
calculation can be made. Step 75 also calculates 

25 Erlang C for n-i-1, the next larger integer. 
According to the invention, the following 
approximation is exploited: the percentage reduction 
or *drop* for one more agent is nearly constant; 
i.e., if n-f-1 yields a C(n-t>l,a) 10% less than that 

30 for n+1, then C(n<f2,a) would be a little more than 
,10% less than that for More specifically, 

assume that for n (which is equal to a^l) 90% of 
calls are forced to wait and that when one more 
agent is added (n^i-l), the percentage of those calls 

35 forced to wait drops to 80%. Using this example, a 
drop value percentage of (90-80)/90 or 11% is then. 
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br the approximation, what would be expected to 
happen to the percentage of calls forced to wait if 
another agent (n<f2) is added. In other words, since 
11% of 80% is 8.8%, then approximately 71.8% of 
5 calls would be forced to wait if n^2 agents are used 
to receive incoming calls. 

Turning now to the specific roeUiod, at step 77, 
the routine sets the variable PWtn « P{W>t} for 
C(n,a) and PWtnl • P(w>t} for C(n4-l,a). FWtn is the 

10 percentage of calls that wait more than ""t** seconds 
if there are "n" agents (and thus the service level 
associated with «n" agents is (100-FWtn)); FWtnl is 
tlie percentage of calls that wait more than "t" 
seconds if there are "n+l" agents. At step 79, a 

15 test is run to determine whether "n" is the correct 
number of agents by determining if (100-PWtn) is 
greater than or equal to the desired service level. 
If 80, the routine returns **n*' and the routine 
terminates. If (100-PWtn) is not greater than or 

20 equal to the desired service level, at step 81 the 
routine determines whether n^l is the correct number 
of agents by determining if (lOO-PWtnl) is greater 
than or equal to the desired service level. If sO/ 
the routine returns n-i-l and terminates. If not, the 

25 method continues at step 83 to calculate a drop 
percentage value « (FWtn-PWtnl)/PWtn* At step 84, 
an estimated percentage waiting time "ePWt* is set 
equal to PWtnl. At step 85, a loop is carried out 
to calculate ePWt-ePWt-(ePWt*drop) , which determines 

30 how many increments of the drop percentage must be 
made until the value (100-eFWt) is greater than or 
equal to the desired service level. At step 86, the 
number of iterations of the loop plus the value 
(n^l) is then set equal to a predictor value "p.* 

35 In particular, at this point the method has 

located a value (100-ePWt) which is approximately 
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the desired senrice level* The use o£ the loop in 
step 85 is extremely advantageous because it 
obviates those expensive and tine-consuming 
calculations o£ C(n,a) and PWtn (£or numerous 
5 intermediates values o£ "n") which otherwise would 
have been necessary in order to reach the 
approximate desired result* At step 67, the 
conventional Brlang C calculations are performed for 
C(p-l#a)« C(p,B) and CCp-t-l^a). The routine 

10 continues at step 89 to set PWtp-1 - P{W>t) for 
C{p-l,a}, PWtp - P{W>t) for C(p,a) and PWtp4-X - 
P{W>t} for C(p4>l,a). At step 91, a test is done to 
determine if (100-PWtp-l) is greater than or equal 
to the desired service level* If so, the routine 

15 returns "p-1* and the method terminates since p-1 is 
the correct answer. If the test 91 at step is 
negative, the routine continues at step 93 to 
determine if (100-PWtp) is greater than or equal to 
the desired service level. If so, the routine 

20 returns p and the method terminates. If not, at 
step 95 the method tests whether (100-PWp<i>l) is 
greater than or equal to the desired service level. 
If so, the routine returns p-i-1 and terminates. If 
necessary (if PWp-t-l is not greater than or equal to 

25 the desired service level) , the method continues at 
Step 97 to perform another loop for m-p-i-2 as 
described until PWt is greater than or equal to the 
service level for m«ro^l and PWt«P(W>t} for C(ro,a). 

Therefore, according to the method of FIGURE 7, 

30 two initial guesses (namely, the minimum number of 
agents n and n-fl) are used as predictor values and a 
first loop is run up in step B5 to determine a value 
(100-ePWt) which is approximately the desired 
service level. At this point, the method checks the 

35 estimate by calculating Erlang C for p-1, p and 
p-fl. Calculating the actual C(p-l,a), C(p,a} and 
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C(p4l,a) and service level exact values, one of the 
three is hopefully a winning value. Generally, the 
winning value will be the central predicted value p 
for most common input data. Stated differently, the 
5 routine uses the numbers for n and n^l to predict 
the value "p" which brings a result close to the 
desired objective. The Erlang C loop is then 
continually run up to calculate C(p-l,a), C(Pfa) and 
C(p-i>l,a). Typically, a winner will be find in one 
10 of these three results; if not, the routine keeps 
running from p<fl, P'*-2, etc. until it does find the 
winner. 

The force management system of the present 
invention also provides significant management 

15 capabilities as compared to prior art systems and 
techniques. The central computer 12 administrative 
functions (e.g., MU allocations) are controlled by a 
team supervisor responsible for long-term planning 
and oversight of the entire team of agents. 

20 Management units ,^ to the contrary, are preferably 
responsible for daily schedule management and are 
thus controlled by an in-charge or "shift" 
supervisor. This architecture dictates that the 
various responsibilities of the supervisors, 

25 especially at the KU level, are dictated by the 
capabilities of that portion of the system for which 
they are responsible. Stated differently, the force 
management system is organized functionally into 
different areas of responsibility, such as planning, 

30 managing, administration, etc. Therefore, efficient 
security controls and the like can be readily 
implemented into the system. 

As noted above, the force management system 
in^lements a unique user interface at the management 

35 workstation (of the central computer 12) and the MU 
workstations. With reference now simultaneously to 
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FIGURES a schedule management screen 60 and a 

performance analysis screen S2, respectively, are 
shown. These screens are implemented at the KU 
workstation to enable the in-charge supervisors, by 
5 shifting back and forth therebetween, to make 
informed staffing decisions for their management 
units. Referring now to FIGURE S/ the schedule 
management screen 60 is built around the display of 
an agent list 61, a timescale 63, an array of 

10 schedule activity codes 65, and a net staffing field 
67. The array is subdivided into a "time line" 64 
for each agent of the management unit, with each 
unit in the time line preferably corresponding to 
predetermined period of time, e.g., fifteen minute 

15 intervals. The timescale 63 preferably displays 
each "hour," with quarter hours represented by dots: 

AM ""wi 
8...9...10..1X..12..1...2...3...4...5...6...7...B 



20 



25 



30 



35 



The time line 64 for each agent includes one or more 
user-defined schedule activity codes 66 therein, 
e.g., "B" for break, "L" for lunch, "m" for 
meetings, etc., for representing the agent's status 
and/or the nature of any activities that prevent the 
agent from attending to incoming calls. 

As shown in FIGURE 8, the time line 64 begins 
with the schedule start time of the first (i.e., 
top) agent displayed. The time line 64 thus begins 
at the first scheduled 15 minute time period of the 
first agent listed. Scrolling to the left or right 
using conventional cursor keys permits the operator 
to view additional scheduled hours. When scrolling 
occurs, the start and stop times on the time line 
scroll as well. 
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As seen in FIGURE 8, the schedule manageinent 
screen 60 designates a number of function keys in a 
lower field 65 of the screen. According to the 
invention* the systein includes suitable program 
5 means, responsive to depression of a Sort function 
Ke7/ for performing one or more sort functions. For 
example # agent names can be sorted in alphabetical 
order. Agent schedules can be sorted according to 
various start time(s) or ending tiroe(8) beginning 

10 with the earliest start time or the latest ending 
time(8). Agents can be sorted hj other user-defined 
criteria such as the members of a carpooKs), those 
agents having a lunch break at 11:30# or the like. 
The system also includes program means responsive to 

15 depression of a Find function key for enabling the 
operator to locate an agent. Once located, that 
agent is at the top of the agent list and thus the 
time line may shift depending on whether the located 
agent has a start time different from the first 

20 agent previously displayed. As also seen in the 
figure, the screen 60 also identifies a Switch 
function key. Depression of the Switch function key 
toggles the display to the performance analysis 
screen 62 of FIGURE 9. 

25 The schedule activity codes 66 are preferably 

color-coded and represent the status of the agent, 
namely, whether the agent is "Open* and thus able to 
handle calls or "Closed* and the reasons therefor. 
Status codes may have different letters identifying 

30 different reasons for unavailability such as "B" for 
break, "L" for lunch, etc. By way of example only, 
the following codes and their color representations 
may be used: 



35 
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Code 



Color 



Meaning 



Period 



White 
Red 



Scheduled open (on calls) 
Closed, out of office 
Closed/ at lunch 
Closed, on break 
Closed, but available to 



5 



-D- 
•L- 
•B- 



Green 
Green 
Yellow 



-c- 

•2- 



Light Blue 
White 



open 

Closed key office functions 
Overtime Type 2 



The activity codes are edited within the time line 
boundary. The time line may be extended by special 
overtime codes. Changes are made by positioning a 
cursor on the required time slot and replacing the 
current scheduled state with the desired scheduled 
state. The display 60 also includes the net 
staffing field 67 which identifies quarter-hour 
staffing summary data depending on the cursor time 
line position. This data includes the number of 
required agents for the quarter-hour increment, the 
total number of agents whose current state is Open 
(i.e., available to handle an incoming call), a Net 
value equal to the number of Open agents minus the 
number of required agents, and a number of Closed 
Available agents, i.e., agents then presently 
working on administrative functions (recordkeeping, 
etc.) but that can be made available to receive 
calls. Preferably, the Met value is displayed in 
red when its value is negative and displayed in 
green when its value is positive. 

The schedule management display thus provides a 
unique time line (as opposed to a textual) 
representation of agents within a management unit to 
enable the supervisor to visualize occupancy and 
potential staffing problems. The schedule 
management displsy cooperates with the related 
performance analysis screen 62 of FIGURE 9 which 
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enables the in-charge supervisor to obtain a 
meaningful view of what call activity has actually 
occurred, a best guess estimate of what call 
activity will occur, and a means of making staffing 
5 decisions based on such information. By switching 
back and forth between the schedule management and 
performance analysis screens, the supervisor can 
make fast, informed staffing decisions. 

with reference now to FIGUBE 9, the details are 

10 shown of the performance analysis screen 62 during a 
forecast mode of operation. As will be described in 
more detail below, the system also includes an 
intra-day reforecasting capability and thus the 
performance analysis screen can also operate in an 

15 intra-day mode showing real-time reforecasts for 
remaining half -hour intervals of the workday. The 
screen includes a Management Unit identifier field 
70 to identify the MU performance data being 
displayed. The performance analysis screen shows 

20 the MU's allocation of team data. In the forecast 
mode of operation, as shown in FIGURE 9, the screen 
displays the data that was originally forecast for 
the particular day (before any intra-day 
reforecasting is performed) . A date/time field 72 

25 identifies the date and the actual time. A Time 
column 74 separates the data into preferably 
half-hour increments beginning with the shift, in 
this case 8:00 a.m. The performance data includes 
the following data fields: Calls 76, average 

30 handling time (AHT) 78, Occupancy 80, Service Level 
82, Staff 84 and Over/Under 86. 

The Calls field 76 has two subfields, "Fore" 
and "Act." "Fore" represents the original forecast 
call values for the half -hour increments and "Act" 

35 is the actual number of incoming calls provided from 
the MIS (and thus updated every half hour). The AHT 
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field 78 likewises includes a Fore and Act subfield 
to display the average handling time per call as 
originally predicted and as measured by the HIS. 
The Occupancy field 80 includes a -Goal* subfield 
5 and an *Act" subfield to display predicted and 
measured levels of staff occupancy, respectively. 
Occupancy data is displayed as a percentage. The 
Service Level field 82 includes the -Fore" and "Act" 
subfields identifying the predicted and measured 

10 service levels, respectively, expressed as the 
percentage of calls answered within a given amount 
of time. The Staff field 84 includes three 
subfields: "Open," "Req" and "Act." The Open 
subfield identifies the number of scheduled open 

15 staff, i.e., agents available to handle calls. 
"Reg* is the number of required staff, and "Act" is 
the number of staff actually there. At any one 
tine, either the Open subfield or the Act subfield 
has data (the other being blank) . The Open subfield 

20 is shown for future periods for which there is no 
HIS data yet. The Act subfield is shown for those 
time periods for which there is HIS data. Finally, 
the Over/Under field 86 represents the difference 
between the number of required "Req" staff and the 

25 number of actual "Act" or scheduled Open (depending 
on which is shown) staff. Positive numbers indicate 
an over-capacity condition, while negative numbers 
indicate under-capacity. Negative numbers are 
preferably displayed in red to insure that the 

30 operator is immediately aware of the potential 
problem. 

The performance analysis screen includes a 
number of function keys 88. The Switch key toggles 
the display back to the Schedule Hanagement screen 
35 of FIGURE 8. Depression of the Intra Key enables 
the operator to change the mode of operation to an 



wo 92/07318 



-33- 



PCr/US91/07513 



*intr8*da7 reforecasting mode.* Zntra-day 
forecasting continually looks at the performance of 
the system and the original forecast data up to the 
time of the day for which data has been received. 
5 Using a reality weighting factor, which takes into 
consideration the amount of data received (i.e./ how 
early in the day the intra-day reforecast is being 
computed) , the system ref orecasts the conditions 
expected for the rest of the day. The intra-day 

10 mode is entered upon depressing the Intra key of the 
terminal. The Xntra~day forecast is accomplished by 
applying a ratio of actual to forecast data to each 
of the remaining cells (i.e., half-hour increments) 
that have no real data, moderated by a reality ratio 

15 as will be described below in more detail with 
respect to FIGURE 10. 

According to another feature of the invention, 
local staffing changes at the MU level (which as 
described above are implemented by the in*charge 

20 supervisor) are transmitted back to the central 
computer databases and are rebroadcast back 
(preferably in real-time as data is received) to all 
effected management units in the system. Therefore, 
all of the MU supervisors can continuously view the 

25 team statistics even as local staffing changes are 
dynamically implemented at other management units. 
Referring briefly to FIGURE 9, the AHT, Occupancy 
and Service Level fields reflect team data while the 
Calls, Staff and 0/U fields reflect KU data, after 

30 allocation based on the appropriate MU percentage. 

The system also provides a "what-if capability 
to allow the call center supervisor or in-charge 
supervisor, as the case may be, to play "what-if 
games with the number of scheduled open agents for a 

35 particular time period. Thus, the call center or 
"team* supervisor can monitor the forecasted call 
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activity £or the entire team and can see the effects 

on team service level df altering the number of open 

agents for the rest of the shift. For example, if 

the HQ supervisor desires to determine the effects 

5 of some unexpected agent absences, an Mbr Open key 

of the terminal is depressed. When the Key is 

struck^ a detail window appears on the screen: 

"Number Open of for HH:HM produces 

Service Itevel of XXk" 

10 The entry field will default to the value (number) 
of Open key agents displayed on the current Schedule 
Management screen. The HH:HM reflects the time row 
that the cursor was positioned on when the function 
key was depressed. When the a new value of the 

15 number of open agents is entered, the system 
calculates the expected service level for the 
period. The cursor stays on the entry field so that 
different values may be tried. Once the effects of 
the absences are determined, the in-charge 

20 supervisor can toggle back to the schedule 
management screen and modify agent schedules 
accordingly if necessary. 

Referring now to FIGURE 10, data flow within an 
MU workstation is shown in detail. The workstation 

25 datastores are those required by the system to 
support local (i.e., MU) needs of the in-charge 
supervisor for a particular MU. Thus, the data 
brought down and stored at the workstation is only 
that necessary and sufficient for MU management. As 

30 seen in FIGURE 10, the workstation includes an 
Individual Schedules dataset 102 which contains the 
schedules of a particular day for the agents of a 
particular MU. A Results dataset 104 contains the 
actual call voltune and agent performance statistics 

35 recorded for the entire team at half-hourly 
intervals. It is a replica of the set stored on the 
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central computer, but generally only the actual data 
for the current shift is stored locally. A Detailed 
Forecast dataset 106 contains the predicted 
half-hourly call volume and AHT. Carried with this 
5 dataset are the HU allocation numbers for the 
corresponding half hour periods. An KU Allocations 
dataset lOB provides the definitions of the MU 
allocation numbers. The definitions give the 
percentage of the incoming calls directed to 

10 particular MU's. 

The workstation includes two build functions: a 
build performance analysis screen function 110 and a 
build schedule management screen function 112. As 
described earlier, the in-charge supervisor can 

15 toggle or "hot-key- back and forth between these two 
functions* The build performance screen function 
110 operates as follows. Assume that at the start 
of the shift there is no past data for that shift, 
i.e. there is no data in the workstation Results 

20 dataset 104. Thus, the data to be written to the 
screen is forecast data from the workstation Detail 
Forecast dataset 106. Referring briefly back to 
FIGURE 9, the first column to be written is the 
forecast Calls 76 allocated to that particular MU. 

25 The build function 110 derives the MU call volumes 
from combining the team call volume predicted for 
the shift in the Results dataset 104 and the MU 
allocation from the HU Allocation dataset 108. As 
described previously, the screen items AHT, 

30 Occupancy and Service Level are all team parameters 
and are taken from the Detailed Forecast dataset 106 
directly. 

The Staff column B4 of FIGURE 9 is the staffing 
for the MU. The required HU values (Reg) are 
35 calculated from the required team values and the MU 
allocations for the shift. The number of Open 
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agents £or the shi£t is calculated by subproeess 1X4 
from the mrkstation' s Individual Schedule dataset. 
After the end of every half hour period, actual 
performance data is received from the central 
5 con^uter 12. The team values for that half -hour, 
namely, AHT, Occupancy and Service Level, are 
written directly from the data. The HU Call Volume 
is calculated from the ml allocation of the actual 
team call volume. MU Required staffing remains 

10 unchanged and the actual MU staffing is obtained 
frcmi the central computer by way of the MIS. 

As described above with respect to the 
intra-day ref orecasting capability, every half hour 
throughout the shift, the call volumes for the rest 

15 of the shift are recalculated based on the actual 
call volume data received earlier in the shift. The 
recalculation is performed by subproeess 116. 
Again, the calls are forecasted for the HU on an 
allocated basis. The number of MU agents required 

20 for the reforecast MU call volumes is calculated 
using an Erlang C method. These reforecasted values 
do not have to be stored or sent back to the main 
computer data base. 



25 provided by subproeess 116 can now be described. 
According to the technique, a reforecast ratio (Rf) 
is first generated equal to the summation of Actual 
data divided by the summation of Forecast data for 
periods having actual data. A so-called reality 

30 ratio is then generated and is defined as equal to 
[N/(N*fl)]^, where M is the number of periods of 
actual data. The following is an example of this 
calculation: 



An example of the intra->day reforecasting 
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The reforecast ratio (R£) - (1204^180) /(lOO-i-lSO) - 
1.2. The reality ratio (Rl) - [2/3]^ « 0.445, since 
li»2« The reforecast value for a subsequent period 
Pt having an initial value (Vp), is then found from 

'5 the equation: v-Vp*[(l<i-(Rf.l))*Ri] . In this case, 
the reforecast value for the third period is then: 

V3 • 200*t(l+(1.2-l))«.445] - 217.8 
When actual MIS data is received, the reforecast 
process is automatically redone. This ref orecasting 

10 is done against the original data, not against the 
reforecast base. That is, if a reforecast has 
increased a call volume by 25%, the automatic 
reforecast works against the base not the reforecast 
number. 

15 Referring back to FIGURE 10, the final 

subprocess for the Performance Analysis Screen is 
the subprocess 116 which provides the "what-if" 
capability of recalculating the Service Level for 
changes in the number of Open agents. The latter 

20 capability is purely a passive "what-if* function 
and the results are not stored. 

Turning now to the build schedule management 
screen function 112 # the timelines for the agents 
are provided from data received from the Individual 

25 Schedules dataset 102. The build function 112 
generates the Schedule Management screen of FIGURE 
8. Active management changes are made by the 
"in-charge* supervisor by the process 120. Such 
changes are then immediately sent to the Individual 

30 Schedule dataset 102 and a corresponding dataset 
(not shown) located at the central computer. A send 
requirements subprocess 122 transfers requirements 
information from the build performance analysis 
screen function 110 to the build schedule management 

35 screen function 112. A central computer data 
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handler function 124 handles the data traffic 
betmen the main computer and the workstation. 

The list of MU agents and their schedules are 
obtained from the workstation Individual Schedules 
5 dataset 102. The net staffing field 67 represents 
the staffing requirements for the current quarter 
hour as determined by the position of the cursor 
relative to the schedule timescale 63. The first 
three variables of the net staffing field are 

10 obtained from the corresponding performance analysis 
screen and are adjusted to reflect quarter-hour 
requirements. The Closed Available value is 
obtained from the Individual Schedules dataset 102. 

The force management system of the present 

15 invention also includes the capability to 
efficiently generate optimal workshifts ("tours*") 
for agents and to generate schedules to satisfy 
agent preferences, availability and seniority. The 
tour/schedule generation method uses the following 

20 conventions : 

1) "requirements" to mean a forecasted need 
for staffing, in quarter-hour intervals for some 
time period (e.g., a week), 

2) ''constraints* to mean the tour templates 
and their rules governing work schedules (e.g. 

25 amount of time worked, number of breaks, days and 
times of agent availability), 

3) "preferences" to mean per-agent desires 
for particular kinds of work schedules within the 
limits imposed by the constraints, and 

3Q 4) "selection policy" to mean precedence 

rules for deciding which agents work when staff 
supply exceeds the need. 

The preferences desirably supported (in priority 
order) are: number of days worked, which days are 
worked and which are off, number of days for 

35 

particular templates, which days are worked for 
particular templates, tour start times and lunch 
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times* The task of schedule generation is to find a 
set of schedules, talcing all the above factors into 
account, that are good or optimal according to some 
evaluation criteria. Examples of such criteria 
5 might be minimising total overstaffing without 
allowing any understaf fing, doling out available 
work time fairly among part-time personnel, 
minimizing labor cost while meeting at least 95% of 
projected staffing requirements, or many others. 

10 The tour /schedule generation method is shown in 

FIGURE 11. The main routine begins at step 130. 
For each agent who may be used, this step calculates 
the days and time intervals and days the agent may 
possibly work. This set of days and time intervals 

15 is then called the "coverage" contributed by that 
agent. At step 132, all the agent coverages are 
added together to get total coverage for each 
interval of each day. 

The method evaluates candidate tours based on a 

20 sum of the values assigned to each interval the tour 
covers. Using the staffing requirements and the 
tour evaluation heuristics, the method continues at 
step 134 to create a two-dimensional evaluation 
array (one dimension is the day of the week and the 

25 other is each 15 minute Interval of the day) 
containing a running sum of the values for each 
interval of each day. By using this array it is 
possible to rapidly evaluate a candidate tour by 
looking only at the endpoints of its times worked. 

30 At step 136, using the staffing requirements and the 
previously calculated available coverage, the method 
then determines the priority order of days for tour 
generation. In this step the days are sorted by the 
ratio of requirements to available coverage. 

35 While there are still days with requirements 

that can be satisfied, the method continues at step 
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13B to determine which day is the highest priority 
day among those for which tours can still be 
generated. Using the agent selection criteria and 
ten^late evaluations, the method continues at step 
5 140 to choose the agent for whom a tour should be 
generated. At step 142, a selection is made from 
among the ten^lates available for the agent. In 
particular, the method selects the template and the 
variation of that template that has the highest 

10 *merit" according to the evaluation array, subject 
to general and agent-specific constraints. At step 
144, the available coverage and the priority order 
of days is recalculated. 

If at this point extra tours must be generated 

15 because of agent constraints (e.g. minimum days per 
week of work) , the routine continues at step 146 and 
generates such tours as follows. While there are 
agents for whom more tours must be generated, the 
routine begins at step 146 by selecting the next 

20 agent (in no particular order). At step 150, the 
highest priority day for which that agent can work 
and does not already have a tour is then selected. 
The best tour variation is then generated at step 
152 as described above. This subloop terminates 

25 upon recalculating the available coverage and the 
priority order of days in step 144. 

The main routine continues at step 156 by 
making a pass through all the generated tours, 
re-adjusting break times to improve smoothness of 

30 the requirements coverage. At step 158, a pass is 
made through the generated tours looking for any 
that can be eliminated without violating staff 
requirements or agent constraints. Thereafter* at 
step 160. a second pass is made, re-adjusting break 

35 times. 
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At step 162, the routine then begins a pass 
through the generated tours for each type of 
preference supported. In each case, the method 
tries to trade tours or breaks among agents to 
5 inprove the match between assigned tours and agent 
preferences, without violating any hard constraints 
or higher-priori tr preferences. 

The following is a pseudocode listing of 
several of the subroutines of the main routine 
10 described above in FIGURE 11: 



CALCULATING AM AGENT'S COVERAGE 

For each tour template the agent may use on a 
given day: 

Mark as covered all intervals from the 
earliest allowed start to the sum of 
(latest start time plus tour length plus 
maximum split length. 

If the template has a required split and 
all combinations of tour start and split 
20 length would leave some intervals within 

the split, unroark those intervals. 

If the allowed slack in tour start time 
and break start times are such that some 
intervals will be within a break under any 
template variation, unmark those intervals. 

25 

Logically OR the marked intervals with 
those marked from other templates. 

Marked intervals constitute the agent's 
coverage. 

CHOOSING AN AGENT FOR TOUR GENERATION 

30 

For every agent in the pool from which the 
routine is working: 

If the agent already has a tour for this 
day or the agent is not available to work 
this day, do not choose this one. 

35 

If this agent must be used and if this day 
is necessary to make the agent's minimum 
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10 



20 



25 



30 



allowed work days, choose this agent 
iinaiedlBtely. 

I£ the current provisional choice does not 
have his/her minimum days requirement 
satisfied and the agent being examined 
does, do not choose this one. 

If the routine has gotten this far, 
calculate the figure of merit for each of 
the agent's available tour templates. If 
no templates work for this day« don't 
choose this agent. Otherwise, note the 
merit figure for the best of the templates. 



If there is no current provisional choice, 
if the provisional choice has his minimum 
days already and this agent does not, or 
if this agent's template merit is better 
than that of the current provisional 
choice, make this agent the provisional 
15 choice. 

If this agent's merit figure is less than 
that of the provisional choice, don't 
choose this agent. 



At this point, both a current provisional 
choice and this agent qualify to be chosen, and 
both have equal template merit figures. 
Determine the new provisions choice based on 
the following comparisons: 

If both agents prefer to have this day 
off, make the less senior agent the 
provisional choice. 

If only one of the agents prefers to have 
this day off, make the other one the 
provisional choice. 

If neither agent wants this day off, make 
the more senior one the provisional choice 
unless getting this tour would cause that 
agent to exceed his preferred number of 
days worked. 

SELECTING THE TEMPLATE FOR TOOR GENERATION 

If the agent has only one template or only one 
that is valid for the day being handled, choose 
35 that one. 
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Determine the "slack" associated with each 
template. That is, the number of days for 
which other templates may be chosen without 
violating the minimum-use constraints for this 
template. 

5 For every template available to the agent on 

this day: 

If agent availability conflicts with the 
use of this template, do not choose it. 

If "slack" considerations force the 
selection of a template other than this 
one, do not choose this one. 

If choosing this template on this day 

would cause a conflict between the 

template's maximuro-use constraint and its 
forced-days constraints, do not choose 
this template. 

15 

If the routine has not disqualified the 

template, calculate the merit of the 
template's best variation. 

If this template's merit is the best so 
far, make it the provisional choice. 

CHOOSING THE BEST VARIATION OF A TEMPLATE 

Adjust earliest and latest allowed start tiroes, 
if necessary, to account for agent 
availability, for "forced preference" start 
time, and for "consistent start time" 
constraints. 

25 

For all allowed start times: 



For all allowed split lengths: 

Form a candidate tour with the given 
start and split values. 

Set the break within their allowed 
ranges so that they minimize the 
maximum requirement values in the 
break interval. 

Calculate the merit value for this 
variation using the evaluation 
35 array. If it exceeds the best so 

far, make this variation the 
provisional choice. 
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VALUATIOM OF lilTERVALS CXHTERED B7 A TEMPLATE OR TOUR 

Set the interval's merit value to zero. 

If the current staffing requirement for an 
interval is equal to the maximum staffing 
5 requirement for the day, add the greater of 

(100) or (100 times the interval's staff 
requirement) to the merit value for the 
interval. 

If the staff requirement in the interval is 
greater than zero, add 10 times the staff 
,0 requirement to the interval's merit value. 

Otherwise, add the (non-positive) staff 
requirement to the merit value. 

It should be appreciated by those skilled in 
the art that the specific embodiments disclosed 
above may be readily utilized as a basis for 
modifying or designing other structures for carrying 
out the same purposes of the present invention. It 
should also be realized by those skilled in the art 
that such equivalent constructions do not depart 
from the spirit and scope of the invention as set 

20 

forth m the appended claims. 



25 



30 



35 
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What is claimed is: 
1. A method for planning, scheduling and 
managing personnel in an environment in which there 
5 is a varying iforkload by time of day and by day of 
week to be staffed with a team having a variable 
number of servers, comprising the steps of: 

(a) organizing the team of servers into a 
plurality of management units, each management unit 

10 having one or more groups of individual servers; 

(b) defining one or more tour templates each 
describing a bounded work shift having work rules 
and operating constraints; 

(c) generating a forecast of an event, load 
15 expected to occur during a forecast time period and 

a number of servers required to service the expected 
event load during the forecast time period; 

(d) allocating the expected event load among 
the plurality of management units according to a 

20 predetermined number of servers expected to be 
available at each management unit during the 
forecast time period; 

(e) correlating the tour templates with the 
forecast to generate a set of tours for each 

25 management unit, each tour defining a work schedule 
for the forecast time period for a theoretical 
server of the management unit; 

(f) assigning the individual servers of each 
management unit to the generated tours for the 

30 management unit; and 

(g) generating a schedule for each individual 
server of the management unit. 

2m The method as described in Claim 1 further 
35 including the step of: 
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(h) managing each senrer's schedule during the 
forecast time period. 

3. The method as described in Claim 2 wherein 
5 steps (£)-(h) are performed in the management units. 

4. The method as described in Claim 3 further 
including the step of: 

(i) rebroadcasting changes made to a server's 
10 schedule in a management unit to the other 

management units of the team. 

5. The method as described in Claim 1 further 
including the step of: 

IS (h) modifying the allocated expected event 

load among the plurality of management units during 
one or more portions of the forecast time period. 

6. The method as described in Claim 1 wherein 
20 at least one or more of the management units are 

physically separated from each other. 

7. A force management system for planning, 
scheduling and managing personnel in an environment 

25 in which there is a varying workload by time of day 
and by day of week to be staffed with a team having 
a variable number of servers, comprising: 

means for generating a forecast of an event 
load expected to occur during intervals of a 

30 forecast time period and a number of servers 
required to service the expected event load during 
each interval of the forecast time periods- 
means responsive to the forecast for generating 
tours for the servers, each tour defining a work 

35 schedule for the forecast time period for a 
theoretical server; 
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means for receiving the tours and assigning the 
servers to the tours; 

means for generating a schedule for each 
server; and 

5 means for managing the server schedules during 

the forecast time period, the managing means 
including : 

a display; 

means for generating a schedule management 
10 screen on the display, the schedule management 

screen including a timescale and a set of 
schedule activity codes for each server 
juxtaposed with the timescale to indicate the 
server's availability to respond to an event 
15 during the server's schedule; and 

means for generating a performance 
analysis screen on the display, the performance 
analysis screen including a timescale 
representation of the intervals and call 
20 handling performance data for each interval 

comparing actual event load during the forecast 
time period with the event load expected to 
occur during the forecast time period. 

25 6. The force management system as described 

in Claim 7 wherein the managing means further 
includes : 

means for processing actual event load data 
during the forecast time period and generating a 
30 reforecast of event loads expected to occur during 
remaining intervals of the forecast time period and 
a number of servers required to service the expected 
event load during each remaining interval of the 
forecast time period. 

35 
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9. The force nanagenent system as described 
in Claim 8 wherein the managing means further 
includes: 

means for receiving the reforecast and 
5 refreshing the data on the performance analTsis 
screen to reflect the reforecast for the remaining 
intervals of the forecast time period. 

10. The force management system as described 
10 in Claim 7 wherein the managing means further 
includes: 

means for editing the schedule activity codes 
in the schedule management screen to modify server 
schedules ; and 

15 means for refreshing the data on the 

performance analysis screen to reflect how the 
edited schedule for the server affects the call 
handling performance data. 

20 II. A schedule management display in a force 

management system, the force management system 
including means for generating daily work schedules 
for a plurality of agents and processing means for 
controlling presentation of data on the schedule 
25 management display, comprising: 

a first area on said display designated to 
display a list of agents; 

a second area on said display designated to 
display a timescale beginning with a scheduled start 
30 time; and 

a third area on said display underlying the 
second area and designated to display schedule 
activity codes corresponding to the daily work 
schedule generated for each agent in the list. 



35 



-49- 



FCrAJS91/07313 



12. The schedule management display as 
described in Claim 11 wherein the timescale 
identifies each hour of a daily shift and includes a 
representation for each quarter hour. 

5 

13. The schedule management display be 
described in Claim 12 wherein the schedule activity 
codes for each quarter hour of the daily shift are 
located under the timescale to enable an operator to 

10 compare agent work schedules. 

14. A performance analysis display in a force 
managooent system, the force management system 
including means for generating call handling 

15 performance data including forecasted and actual 
call volume data, average handling time data, 
occupancy data, service level data, and staffing 
data, and processing means for controlling 
presentation of the call handling performance data 

20 on the performance analysis display, comprising: 

a first area on said display designated to 
display time representations in predetermined 
increments ; 

a second area on said display designated to 
25 display forecast call volumes and a number of actual 
incoming calls for each predetermined increment; 

a third area on said display designated to 
display a number of scheduled open agents, a number 
of required agents and a number of agents actually 
30 available to handle incoming calls for each 
predetermined increment; and 

a fourth area on said display designated to 
display data for each pretermined interval 
representing a difference between the number of 
35 required agents and the number of actual or 
scheduled agents. 
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15. The performance analysis display as 
described in Claim 14 further including: 

a fifth area on said display designated to 
display forecast and actual average call handling 
5 times for agents during each predetermined increment; 

a sixth area on said display designated to 
display forecast and actual occupancy data 
indicating a percentage of time during each 
predetermined increment in which agents are handling 
10 incoming calls; and 

a seventh area on said display designated to 
display forecast and actual service levels for each 
predetermined increment. 

15 16. A method, using a database of historical 

call volume data, for generating a forecast of call 
volumes expected to occur in a telephone call center 
during a future time span, the historical call 
volume data exhibiting a grotrth rate reflecting 

20 changes in historical call volumes over a 
predetermined first time period ending with a 
previous day, comprising the steps of: 

(a) defining a forecast base period 
corresponding to a predetermined second time period 

25 ending with the previous day; 

(b) for each individual time increment of a 
given day of the week beginning with a first 
individual time increment of a week, continuing 
increment-by-increment and ending with a last 

30 individual time increment of the week: 

(1) averaging the call volume data in the 
forecast base period; 

(2) calculating the standard deviation of 
the averaged call volume data; 

35 (3) discarding any call volume data that 

deviates two standard deviations from the mean; 
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(4) weighting the remaining call volunie 
data with predetermined weighting criteria to 
produce weighted call volume data; 

(5) averaging the weighted call volume 
data to produce a weighted average call volume; 

(6) projecting the weighted average call 
volume into correaponding incrementa throughout 
the future time span; and 

(7) generating a calendar factor £rom the 
forecast base period historical data, the 
calendar factor representing a relative 
weighting of call volumes by week of month; 

(c) if the first day of the future time span 
is not a next day, adjusting the growth rate to 

15 reflect changes therein which would have occurred 
between the previous day and the first day; 

(d) applying the growth rate, as a daily 
exponential rate of change, to the weighted average 
call volumes on a day-to-day basis from the first 

20 day of the future time span to a last day of the 
future time span; 

(e) for each individual time increment from 
the first day of the future time span, continuing 
increment-by-increroent and ending with a last 

25 individual time increment of the last day of the 
future time period: 

(1) generating a seasonality factor from 
the first time period historical data for each 
new month of the future time span, the 

30 seasonality factor representing month-to-month 

percentage increases or decreases in call 
volumes ; 

(2) using the seasonality factor to 
calculate forward and backward net seasonality 

35 factors based on the position in the month of a 

current time increment; 
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(3) retrieving the calender £actor; and 

(4) applTlng the forward and backward net 
seasonality factors and the retrieved calendar 
factor to the weighted average call volume as 

5 adjusted by the growth rate. 

17. A method for planning, scheduling and 
managing personnel in a telephone call center in 
which there is a varying workload by time of day and 
10 by day of week to be staffed with a variable number 
of agents, the telephone call center having means 
for generating call handling performance data 
including average call arrival rate and average 
handling time per call, comprising the steps of: 
15 (a) defining a desired service level for the 

telephone call center equal to a percentage of calls 
answered within a predetermined time "t"; and 

(b) predicting a number of agents required to 
provide the desired service level by: 
20 (1) calculating an offered load "a" equal 

to the average arrival rate of calls for the 

call center times the average handling time per 

call; 

(2) calculating FWtn using an Erlang C 
25 function C(n,a), for n-a-i-1, where FWtn is a 

percentage of calls that wait more than "t" 
seconds if there are "n" agents; 

(3) if (100-PWtn) is not greater than or 
equal to the desired service level, repeating 

30 step (2) for PWtnl, where FWtnl is a percentage 

of calls that wait more than "t" seconds if 
there are "n-Fl* agents; 

(4) if (100-FWtn) is greater than or 
equal to the desired service level, define n as 

35 the predicted number of agents; 
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(5) if (lOO-PWtnl) is not greater than or 
equal to the desired level for n-n<fl, calculate 
a drop percentage (PWtn-PWtnl)/PWtn; 

(6) set an estimated percentage waiting 
5 tine ePWt equal to PWtnl; 

(7) calculate ePWt-ePWt-(ePWt»drop per- 
centage) to determine how many increments of 
the drop percentage must be made until 
(lOO-eFWt) is greater than or equal to the 

10 desired service level; 

(8) set a predictor value p equal to the 
determined number of increments plus (n+1); 

(9) calculating Erlang C(n,a) for n-p-1, 
p and p*l; 

15 (10) repeating steps (3)-(4} for 

successive values of n-p^l^ p and P't-l until a 
value of n is located such that (100-PWtn) is 
greater than or equal to the desired service 
level . 

20 

18. A method for planning i scheduling and 
managing personnel in an environment in which there 
is a varying workload by time of day and by day of 
week to be staffed with a team having a variable 
25 number of servers, comprising the steps of: 

(a) defining one or more tour templates each 
describing a bounded work shift having work rules 
and operating constraints; 

(b) defining per-server preferences for 
30 particular kinds of work schedules within the limits 

imposed by the tour templates; 

(c) defining selection policy rules for 
determining which servers work when the number of 
servers exceeds the demand therefor; 

35 (a) generating a forecast of an event load 

expected to occur during a forecast time period and 



WOf2/073U 



-54- 



PCrAJ591/07513 



a number of servers required to service the expected 
event load during the forecast time period; 

(e) correlating the tour tea^lates with the 
forecast to generate a set of optimal tours, each 

5 tour defining a daily work schedule for the forecast 
tioie period for a theoretical server; and 

(f) automatically scheduling the individual 
servers to the generated tours according to the 
preferences and the selection policy rules. 

10 

19* The method for planning, scheduling and 
managing personnel as described in Claim IB wherein 
the step of automatically scheduling the individual 
servers to the generated tours comprises the steps 
15 of: 

calculating a server's available coverage for 
the tour tenqplates the server may use on a given day; 

calculating a total coverage for all servers 
for each of a plurality of predetermined time 
20 intervals for each day of a week; and 

determining a priority of days of the week for 
tour generation. 

20. The method for planning, scheduling and 
25 managing personnel as described in Claim 19 wherein 
the step of automatically scheduling the individual 
servers to the generated tours further comprises the 
steps of: 

determining whether there are any days of the 
30 week that have staffing requirements that can be 
satisfied; 

if there are any days of the week that have 
staffing requirements that can be satisfied, 
determining which of said days has a highest 
. 35 priority; and 
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selecting a server for whom a tour should be 
generated. 

21. The method for planning, scheduling and 
5 managing personnel as described in Claim 20 wherein 
the step of automatically scheduling the individual 
servers to the generated tours further comprises the 
steps of: 

selecting a tour template for the server; and 
10 generating a tour for the server using the 

selected tour template. 
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